The Transmission Control Protocol/Internet Protocol (TCP/IP) suite that forms the basis of the Internet was designed and optimized to operate in a terrestrial environment. Despite this fact, TCP/IP will operate over an extremely large range of link conditions, albeit at reduced levels of performance when the assumptions inherent in its algorithms are violated. For instance, the high delay-bandwidth product and higher bit error rate of a satellite link results in a situation in which the satellite link is not efficiently utilized and the TCP/IP performance (as perceived by an interactive user) is poor.
The use of wireless links provides a very flexible way to extend networks where a wired infrastructure is not available or is not cost effective, but there are a number of important technical issues that need to be addressed. These issues revolve around the fact that most protocols are optimized to run on terrestrial networks. The primary differences between terrestrial and wireless connectivity are the link latency, the bit error rate (BER), and channel asymmetry. In a terrestrial system, error rate is typically low ( less than 10xe2x88x9210) and the latency is short ( less than 30 ms), while on a wireless link, the BER can range from 10xe2x88x9210 to 10xe2x88x923 and, in some cases, the round trip latency can exceed 1.0 second. In addition, wireless links tend to be asymmetric with some systems having 100 times or more available capacity in one direction than the other.
In some scenarios, the physical characteristics of the wireless link are such that the assumptions about link quality and latency inherent in the TCP design are rendered invalid and poor performance results. In these cases, the poor performance may be attributed to a combination of TCP""s automatic repeat request (ARQ) and flow control (FC) algorithms. The ARQ algorithm uses a combination of strategies that depends heavily on the TCP implementation used at each end of the connection. In some scenarios, especially if the receiving host does not buffer segments received out of order, an ARQ strategy that is not appropriate for a wireless link may result and, performance will be degraded due to unneeded retransmissions and/or inefficient use of the link.
The TCP FC algorithm also may contribute to poor performance on a wireless link. The existing FC algorithm does not differentiate between packets that are lost (due to congestion) and packets that are received in error (due to bit errors). On a terrestrial link the error rate is very low, so almost no packets are received in error. On a satellite link, however, the situation is the opposite, e.g., almost no packets are lost and many are received in error. The result is that TCP detects congestion where there is none and reacts by reducing the transmission rate to alleviate the congestion, causing the link utilization to shrink further. As with the ARQ algorithm, the exact effects are implementation dependent.
Another effect that can be attributed to the FC algorithm is the slow ramp up of data flow. Most Internet communication occurs on short duration virtual circuits. In other words, the virtual circuit is set up, a small amount of data is sent and received, and the virtual circuit is torn down. On a high delay bandwidth product channel, where delay bandwidth product is defined as the data rate of a channel multiplied by the round trip time of the channel, TCP""s slow start algorithm initially takes a long time before it can fully utilize the bandwidth available on a virtual circuit. Slow start is intended to prevent a host from bursting data at the start of a TCP connection and works in the following manner.
TCP has a congestion window that is set to the length of one packet (or segment) at the start of a TCP connection. TCP is only allowed to send up to a congestion window""s amount of unacknowledged data at a time. The rate of increase of this congestion window is such that for every segment that is acknowledged the congestion window grows by the length of one segment. Hence, the congestion window grows exponentially at the start of a connection. Note that in most implementations, acknowledgments are delayed and only every second segment is acknowledged, resulting in sub-exponential growth. The TCP connection is often finished before TCP""s congestion window gets large enough to fully utilize the wireless link.
In accordance with the present invention, a method of communicating over a link which may be a high delay-bandwidth link, such as a satellite link, comprises receiving, at a source gateway, incoming packets directed to a destination address, in a first protocol, preferably transmission control protocol (TCP) over Internet protocol (IP), or TCP/IP. At the source gateway, the destination address is modified so that the packets are forwarded to a source gateway application, or protocol translator, in the first protocol. The original TCP connection is terminated at the source gateway, and acknowledgments are transmitted from the source gateway back to a source.
From the source gateway application, the packets are forwarded in a second protocol over the link to a destination gateway application. The destination address is communicated to the source gateway application, and then to the destination gateway application. In the destination gateway application, the destination address is used to determine where to send packets. Finally, the packets are forwarded from the destination gateway application to the destination address. Preferably, packets are forwarded from the destination gateway application to the destination address in the first protocol.
To maintain a low susceptibility to transmission errors, the packets may be transmitted or forwarded over the link by fragmenting the packets, in the source gateway application, into smaller packets. In the destination gateway application, the original packets are reconstructed from the smaller packets.
Preferably, in the second protocol, upon an automatic repeat request (ARQ) from the destination gateway application to the source gateway application, only packets which are incorrectly received by the destination gateway application are retransmitted from the source gateway application. The packets may therefore arrive at the destination gateway application in scrambled order, and are reordered in the destination gateway application into their original order. Incorrectly received packets are retransmitted K times where K depends on the BER. This ensures that the packets are correctly received within one round trip time.
Information from the source gateway application, comprising the destination address and a channel identifier, is transmitted to and stored at the destination gateway application. The channel identifier is appended to packets before their transmission over the high delay-bandwidth link, and the destination gateway application uses the received channel identifier to identify the stored information.
Preferably, forwarding a received packet to the source gateway application is done by replacing the destination address in the packet with an address of the source gateway application. The original destination address is restored at the destination gateway application.
To reduce acknowledgment traffic, acknowledgments preferably are sent over the high delay-bandwidth link only periodically. Only a list containing the first sequence number and the last sequence number of a series of contiguously received packets is sent back to the source gateway application.
Preferably, a source self-network address translator (SNAT) on the source gateway replaces the destination address of each incoming packet with the source gateway application""s address. The SNAT forwards the original destination address to the source gateway application. The source and destination gateway applications communicate over the high delay-bandwidth link using a second protocol which ensures that the link is error-free and ordered. The destination address is communicated from the source gateway application to the destination gateway application over the link. The source gateway application sends the packets over the link to the destination gateway application.
The destination gateway application in turn forwards the packets to the destination address, preferably using the first protocol by which the addressing information of the destination gateway application is appended to the packets as the source address. The original source address is forwarded from the destination gateway application to the destination SNAT on the destination gateway, and the SNAT replaces the destination gateway application""s address information with the original source address to make the protocol conversion transparent to the final destination.
In a preferred embodiment, a request for a communications session sent by a first end-user to a second end-user in a first protocol is received by a first or source gateway. At the first gateway, the original addressing information of the first protocol is modified, causing the request to be processed by the first gateway. The first communications session or source connection with the first end-user, is established utilizing the first protocol. A second communications session is established with the second gateway, over the transmission medium, utilizing a second protocol.
At the second gateway, a third communications session, or destination connection with the second end-user is established, preferably utilizing the first protocol. The request""s original addressing information is restored.
On the first communications session, packets are forwarded from the first end-user to the first gateway, and from the first gateway to the first end-user. The first protocol is used and addressing information is modified when necessary.
On the second communications session, packets are forwarded from the first gateway to the second gateway, and from the second gateway to the first gateway. The second protocol is used over the second communications session.
On the third communications session, packets are forwarded from the second gateway to the second end-user, and from the second end-user to the second gateway. Preferably, the first protocol is used and addressing information is modified when necessary.
Packets forwarded from the first end-user to the first gateway are preferably forwarded by changing their addressing information to that of the first gateway. The addressing information is changed by a Self Network Address Translation (SNAT) module running on the first gateway. The SNAT module receives an incoming packet which is destined for the second end-user, and checks the addressing information against a list of rules to determine whether the addressing information should be changed. If a rule is matched, the addressing information is changed, and the original addressing information of the packet is stored.
Where the first protocol is TCP/IP, the SNAT module is inserted into a protocol stack of the first gateway below the IP module, and is configured to change the source IP address and TCP port, the destination IP address and TCP port, and the TCP and IP checksums, of the packets.
The SNAT is configured by a protocol translator, or gateway application, running on the first gateway. In addition, the SNAT may change the addressing information of packets sent to particular TCP ports at the second end-user.
A protocol translator on the first gateway receives packets via the first communications session and sends them over the second communications session. The protocol translator receives a start of the first communications session, and then sends a message to the SNAT module on the first gateway, requesting addressing information of the second end-user. A second communications session with a second gateway is established and the addressing information of the first and second end-users is sent to the second gateway. Data packets are received on the first communications session. The packets are processed, and sent on the second communications session. In the reverse direction, data packets are received on the second communications session, processed, and sent on the first communications session.
A second protocol translator on the second gateway receives packets via the second communications session and sends them on the third communications session. Preferably, on the second communications session, the second protocol translator receives the original addressing information of the first and second end-users. A new socket to a new TCP port is opened to communicate with the second end-user. From the second protocol translator, a message is sent informing a second SNAT module on the second gateway that the source addressing information of packets sent from the new socket should be changed to that of the first end-user. A third communications session is established between the second protocol translator and the second end-user.
Data packets are received on the second communications session. The packets are then processed and sent on the third communications session. Data packets are received on the third communications session, processed, and sent on the second communications session. Processing of packets may comprise, but is not limited to, data compression, data decompression, encryption and decryption, or any combination thereof. Compression allows the amount of data that needs to be sent on the wireless link to be reduced, further improving efficiency. Encryption is used to ensure that data sent on the wireless link remains private. The architecture of the present invention allows TCP connections to be compressed independently or in bulk.
Processing may also consist of prioritization and billing. For example, packets from customers who pay for a premium service may be given priority service to the wireless link. In addition, customers may be billed based on the number of packets sent, when they are sent, and what priority they are given.
Preferably, the protocol translator receives all packets modified by the SNAT module on one particular TCP port.
Preferably, the link layer maintains one receive buffer for all sessions between the first gateway and the second gateway. At the link layer, an automatic repeat request (ARQ) algorithm is used to maintain reliability. The ARQ algorithm may be such that an ARQ sender conveys its entire receive buffer state to an ARQ receiver. Preferably, the ARQ algorithm determines whether to send an ARQ message based on the sequence numbers of messages received. Alternatively, the ARQ algorithm determines whether to send an ARQ message based on a period of time.
Preferably, only packets using the first protocol have their addressing information changed.
In an alternate embodiment, forward and return paths of the second communications session use different physical networks and/or physical media. Such asymmetric links drastically reduce system complexity with respect to existing methods.
In yet another embodiment, an end-user and its associated gateway are the same computer.
The present invention improves the performance of the TCP/IP protocol suite in a wireless or other high delay-bandwidth environment, increasing the wireless link utilization and dramatically improving the performance. Software is added to gateways at the periphery of the wireless segment of a network.
The present invention allows higher layer protocols such as TCP to operate seamlessly over wireless networks. Its approach has many advantages. For example, it may be configured to operate completely transparently to end users. In addition, the present invention offers nearly optimal use of wireless links, requires no modifications to end users protocols or applications, and requires no modifications to the protocols on the gateways. Access to operating system or protocol source code is not required, so that the present invention may be used with proprietary third party operating systems and protocol implementations. It can be used to impose any desired notion of fairness and can process data to improve the transmission efficiency on the wireless link. Finally, the present invention can be used as a generic protocol converter or it can be configured to operate as a firewall.
There are many advantages to converting TCP to another protocol at the gateway. For example, because there is no concept of TCP on the high-delay and/or the high error-rate wireless segment, the detrimental effects of latency and errors on TCP are avoided and link utilization is greatly increased. TCP/IP headers are replaced with a much shorter WLP header, leaving more bandwidth for data. In addition, TCP/IP data may be compressed so that fewer bytes need to be sent over the wireless segment, thus improving data transfer times. Encryption may also be used to protect data from eavesdropping. Finally, the system may be implemented without making any changes to the TCP/IP code on the gateway. No changes of any kind are required to the end users.
The present invention""s approach is compatible with all standard TCP/IP implementations and any applications desired. The system may be configured in several different manners depending on the task at hand. In a transparent embodiment, it may be inserted anywhere within an IP network, subject to some weak topological constraints, and will boost performance without making any changes outside of the wireless segment. It can also be configured in a xe2x80x9clast hopxe2x80x9d mode for individual wireless hosts. In this case, the present invention must reside on the wireless host.
Technically, IP makes no assumptions about link quality, offering only a best effort service. However, protocols such as UDP, TCP, ICMP, RIP, OSPF, etc. that ride on top of IP, assume that errors on the link are an exception, not the rule. Therefore, it is important that the impact of link errors be reduced for proper operation of the protocols and applications that use IP. This implies that non-TCP datagrams require some special handling as well. The present invention has been designed to alleviate the deficiencies of these protocols when operating in a wireless environment.